Method and system for split-hashed payment account processing

ABSTRACT

Methods and systems for receiving an authorization request associated with a transaction, the authorization request including an account code; receiving a user code to associate with the account code; associating the account code and the user code together to form a payment account code; determining an account identifier corresponding to the payment account code; determining whether to map the payment account code to a primary account number (PAN); mapping, in response to the determination that the payment account code is to be mapped to the PAN, the payment account code to the PAN to ascertain a PAN corresponding to the payment account code; and sending the authorization request including the PAN to be authorized.

BACKGROUND

Traditionally, a major concern of merchants, cardholders, and issuers ofcredit, debit, charge, and other types of cards and payment devices thatinclude a representation of a primary account number (PAN) on or in thepayment device is the safeguarding and prevention of fraud using thePAN. Typically, the PAN is printed and/or embossed on a surface and/orencoded on a magnetic stripe of the payment device. In some paymentdevices including an electronic element such as, for example, acontactless payment credit card having an integrated circuit and amemory component (i.e., a chip card) and an electronic walletapplication for a mobile device, the PAN may be stored in an electronicformat. A great number and variety fraud prevention measures and schemeshave been proposed and/or implemented in an effort to prevent thefraudulent use of the PAN representations provided with conventionalpayment devices.

Some previous fraud prevention measures and techniques to combat afraudulent use of PANs include, for example, a requirement for a pieceof information in addition to the PAN in the processing of transactionsinvolving the PAN. Some payment processing techniques require a cardsecurity code in addition to or “on top of” the PAN printed on orencoded on a credit card and a debit card transaction may require a userenter a personal identification number (PIN) in addition to the PANprinted on or encoded on a debit card. In the instance the card securitycode is printed on, stored in, or generated by the payment device (e.g.,by a chip card), gaining possession of the payment device or theinformation on and/or in the payment device also results in obtainingthe PAN and the additional information supposed to combat fraud.

Additionally, the fact that core account numbers are still the keyidentifier for PAN activities and PANs may be transmitted and stored byvarious entities in distributed online processing systems, PANs may beat risk of being retrieved by unscrupulous entities that may buy, sell,leverage, use, and otherwise compromise payment processing systemassociated with the distributed systems. As a consequence of theabove-mentioned issues and others, the costs for account issuers relatedto fraud management, charge-backs, and the re-issuance of new cardscontinues to increase.

Therefore, it would be desirable to provide improved methods and systemsfor efficiently facilitating and processing payment card transactionswhere the relevancy of a PAN is reduced in a distributed paymenttransaction processing system.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, wherein:

FIG. 1 is a schematic diagram illustrating various aspects of thepresent disclosure, according to some embodiments herein;

FIG. 2 is a flow diagram of a process, according to some embodimentsherein;

FIG. 3 is a block diagram of a distributed system for processing paymenttransactions, in accordance with some embodiments herein;

FIG. 4 is a flow diagram of a process that illustrates the entitiesassociated with the operations therein, in accordance with someembodiments herein; and

FIG. 5 is a schematic block diagram of an apparatus, according to someembodiments herein.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present disclosure, a payment asset refers to, in general, apayment device of any embodiment (e.g., card, mobile telephone, a keyfob, etc.) that may include a representation of a payment card numberthat is printed on, stored in, or encoded in a credit card, debit card,stored value card, gift card, and other payment cards. As used herein,the payment card number is referred to as the primary account number(PAN). Whereas traditional payment devices may include a PAN embossedon, printed on, or stored thereon, the various embodiments of thepresent disclosure do not have the PAN either printed on, embossed on,or stored in the payment asset(s) that may be issued to a cardholderuser.

As used herein, the user or customer to whom a subject payment device isissued is referred to herein as a “cardholder” even though the paymentdevice may be embodied in a configuration other than a card.

In accordance with some embodiments herein, a 2-factor authenticationprocess is provided for a payment device issued by, for example, afinancial institution and related to a payment account managed by theissuer. In some aspects, an embodiment of a method and system herein mayinclude issuing a payment card asset or device having a first portion ofa payment account code (PAC) printed or stored thereon. The firstportion of the PAC may be stored on or in the payment device if thepayment device has the capability to store the PAC in an encoded formatin, for example, a memory chip, magnetic stripe, etc. The PAC may beassociated with a PAN that identifies a certain payment account. Whilethe PAC may be associated with a PAN, the PAC is not same as or atruncated version or an altered version of the PAN for a particularsource of funds payment account. Neither the PAN, a truncated version,nor an altered version of the PAN is included on or in the issuedpayment device of the various embodiments herein. As used herein, thefirst portion of the PAC is referred to as an account code (AcctCode).

The AcctCode may be created by an issuer for a user cardholder. TheAcctCode may be generated based on an algorithm which, in someembodiments, is related to the Bank Identification Number (BIN) and/orother parameters and fields of a PAN.

A second portion of the PAC may be generated and assigned to the usercardholder. This second portion of the PAC is not included on or in thepayment device and is not typically distributed to the user with adelivery of the payment device. As used herein, this second portion ofthe PAC is referred to as a user code (UserCode). The UserCode may beassigned, by a payment network operator to a user for associating withthe AcctCode issued by the issuer for a particular payment account. TheUserCode may be communicated only to the user cardholder from thepayment network operator. In this manner, the UserCode may only be knownto the payment network operator and the user cardholder. The UserCodemay typically be known (i.e., memorized) by the user.

Together, the AcctCode and the UserCode comprise the PAC. The PAC may beformed by associating the AcctCode and the UserCode with each other. Insome embodiments, the AcctCode may comprise 12 numeric digits, theUserCode may comprise 4 numeric digits, and the AcctCode and UserCodemay be concatenated to form a 16 digit numeric string PAC. The PAC maybe 16 numeric digits in length, similar to a number of existing PANnumbering schemes. However, the PAC and the PAN associated with aparticular payment account are distinct from each other and the value ofthe PAC is not the same as the value of the PAN.

In some aspects, the PAC may be 16 numeric digits in length similar tosome PANs. In this regard, some aspects of the present disclosure may bemore easily and efficiently accommodated by at least some existinglegacy systems and devices involved in the processing of paymenttransactions, including but not limited to merchant POS (point of sale)systems, acquirer systems and payment network systems. Reflective of atotal length of the PAC, in some embodiments the AcctCode may be 10numeric digits long and the UserCode may be 6 numeric digits long sothat the PAC (e.g., AcctCode+UserCode) is 16 numeric digits long. Insome aspects, the PAC may comprise a 16 digit (or other length of)numeric digits formed by the AcctCode having a first set of numericdigits and the UserCode including a second set of numeric digits. In oneembodiment, the AcctCode may be longer than the UserCode since a usermay be responsible for knowing (i.e., remembering) the UserCode. Yet, inanother embodiment the UserCode may be longer than the AcctCode.

Referring to the 2-factor authentication aspect of a payment deviceherein introduced above, the AcctCode printed on, stored on, orgenerated by the payment device may constitute a “possession” factorsince it will be normally carried by the user cardholder and theUserCode may constitute a “knowledge” factor since it will normally beknown by the user.

FIG. 1 is a schematic diagram illustrating various aspects of a system100 that may support and facilitate a number of aspects of the presentdisclosure, according to some embodiments herein. System 100 includes anissuer 105, a payment network operator 110, and a user cardholder 115.

Issuer 105 may generate a PAN for a payment account managed andmaintained by the issuer. Issuer 105 may further generate an AcctCode120 for the payment account and issue a payment device to usercardholder 115, as illustrated via line 135. AcctCode 120 may comprise12 numeric digits in some embodiments. The payment device issued to usercardholder 115 may have the AcctCode 120 printed and/or stored thereon,to the exclusion of the PAN. A record of the PAN associated with theAcctCode 120 may be maintained in a PAN repository 130 that may bemanaged by issuer 105. Issuer 105 may forward a record, message, orother indication of AcctCode 120 used on the issued payment device topayment network provider 110. Based on AcctCode 120 used on the issuedpayment device, payment network provider 110 may generate and assign anaccount identifier (AcctID) 117 to associate with AcctCode 120. In someaspects, payment network provider 110 may store a record or indicationof the association relating to an AcctCode 120 and a correspondingAcctID 117. The record may include, in some aspects, a lookup table, amapping, a database entry, and other data structures to maintain anrecord of the association between an AcctCode and its correspondingAcctID.

Payment network operator 110 may generate a UserCode 125 for the paymentaccount that will be used to comprise the PAC and assigns the UserCodeto cardholder 115. UserCode 125 may comprise 4 numeric digits in someembodiments. In some embodiments, payment network operator 110 maycommunicate UserCode 125 to cardholder 115. In some aspects, UserCode125 is not communicated to cardholder 115 at the same time and in thesame manner used to deliver AcctCode 120 to the cardholder. There may bea separation of at least one of the time and the communication channelused to deliver AcctCode 120 and UserCode 125 to user cardholder 115.

As an example of an illustrative use-case, a user may swipe a contactpayment device or “tap” a contactless payment device in their possessionat a merchant's POS terminal in order to use the payment device inconjunction with a payment transaction. Since the payment device of thepresent disclosure includes AcctCode 120 (not a PAN), AcctCode 120 maybe forwarded to payment network operator 110 in a message such as anauthorization request message for the present payment transaction. Infurther conjunction with the payment transaction, cardholder 115 mayprovide UserCode 125 known by them to payment network operator 110. Insome aspects, UserCode 125 may be submitted via a manual keypad, a touchscreen, an input to a voice recognition system, and other user interfaceinput mechanisms to the merchant's POS terminal for forwarding topayment network operator 110.

In some embodiments, AcctCode 120 and UserCode125 may be forwarded topayment network operator 110 in a common or same message such as, forexample, an authorization request message that may include additionaldetails related to the payment transaction. In one embodiment, AcctCode120 and UserCode125 may be forwarded to payment network operator 110 inseparate messages.

Payment network operator 115 receives, obtains, or determines the PACcomprising AcctCode 120 and UserCode 125. In some embodiments, an entitysuch as an acquirer or an acquirer servicer (not shown in FIG. 1) mayoperate to facilitate, at least, associating the AcctCode 120 andUserCode 125 to form the PAC. In some aspects, the UserCode (e.g., 4numeric digits) is concatenated to the end of the numeric stringcomprising the AcctCode (e.g., 12 numeric digits) to form the PAC (e.g.,16 numeric digits).

In some embodiments, payment network operator 110 may determine theparticular AccctID 117 associated with the received PAC. In someaspects, the AccctID associated with the received PAC may be determined,at least in part, based on a record or mapping of an association ofAcctID 117 with the AcctCode 120 comprising the received PAC.

In some embodiments, the actual PAN generated and issued by issuer 120is managed and maintained in PAN repository 130. PAN repository 130 mayinclude one or more data storage facilities, including for example adatabase management system and one or more memory systems. In someaspects, the PAN is not distributed to or stored by an entity other thanissuer 105 such as a merchant, an acquirer, or payment network operator115 since the PAN itself is not deployed with the payment device or usedin the payment transaction processing before the authorization requestmessage in the sent to issuer 105.

In some embodiments, the actual PAN generated and issued by issuer 120is managed by the issuer and maintained in PAN repository 130, whereinthe issuer may manage distribution of the PAN to a payment networkoperator. Issuer 105 may distribute the PAN to payment network operator110 so that payment network operator 110 may map the received PAC to thePAN. In some aspects, payment network operator 110 may determine themapping or association between the PAC and the PAN, at least in part,based on a record or mapping of an association of AcctID 117 with theAcctCode 120 comprising the received PAC. The PAN determined by paymentnetwork operator 110 may be passed or sent to issuer 105 in anauthorization request message for authorization.

In some aspects, once the PAN is sent to or determined by issuer 105,all processing of the authorization request message, as well asclearing, settlement (e.g., charge-backs, etc.), card management, andlicensing may be performed with the actual PAN.

FIG. 2 is a flow diagram of a process 200, according to some embodimentsherein. In particular, process 200 may reflect a method to process apayment transaction or purchase transaction (i.e., a transaction) by apayment network operator, service, server, or servicer according to someaspects herein. At operation 205, an authorization request associatedwith a transaction is received. The authorization may be received froman acquirer or acquirer agent related to a merchant participating in thetransaction. In a departure from conventional transactions, theauthorization request may not include a PAN issued by an issuer andcorresponding to a payment account. Instead, the authorization requestof operation 205 may include an account code, AcctCode, issued by theissuer, where the AcctCode is separate and distinct from the PAN and hasa value that is not the same as the PAN's value. The issuer may issuethe PAN however the PAN is not distributed on a payment device or storedby other entities in accordance with some aspects herein.

At operation 210, a user code, UserCode, is received from a user. TheUserCode is to be associated with the AcctCode, where the AcctCode andthe UserCode together form a payment account code, PAC, that will beused in the process of the transaction and act as representativeidentifier for the payment account maintained by the issuer. In someaspects, the UserCode may be supplied by the user cardholderparticipating in the transaction. It is noted that the UserCode may beneed to form the PAC, as opposed to being a value supplied in additionto the PAC. In some instances, the UserCode and the AcctCode may both bereceived in the authorization request or some other same message, Insome regards, the UserCode may be received in a message separate fromthe AcctCode.

At operation 215, the AcctCode and the UserCode are associated togetherto form the PAC. The associating of operation 215 may includeconcatenating the UserCode to a trailing (or leading) edge of theAcctCode. Other embodiments of operation 215 may involve other methodsof obtaining or determining the PAC based on the AcctCode and UserCode,including, for example, substituting at least the received AcctCode withat least a portion of the UserCode, transforming the AcctCode andUserCode based on a predefined relationship or algorithm, and othertechniques.

At operation 220, an account identifier, AcctID, corresponding to thePAC is determined. The AcctID may be a specific, non-PAN identifiergenerated by the payment network operator that is associated with theissued payment device that includes the AcctCode. In some embodiments, arecord or other indication of the AcctCodes and corresponding AcctIDsmapped thereto may be maintained by the payment network operator.

Continuing to operation 225 of process 200, a determination may be madeto determine whether the payment network operator is to map the PAC tothe PAN. The determining of operation 225 may be based on, at least inpart, on whether the payment network operator manages the PAN for theissuer of the PAN or whether the issuer (or an agent thereof) managesthe PAN.

In an instance it is determined at operation 225 that the paymentnetwork operator manages the PAN for the issuer of the PAN and as aconsequence the payment network operator is to map the PAC to the PAN,then the PAC is mapped to the PAN at operation 230. The PANcorresponding to the PAC is thereby obtained. The PAN may then be sentto be authorized in an authorization request, as indicated at operation235. The PAN may be used in the further processing of the transaction,including, for example, clearing, settlement, and other payment device(e.g., card) management functions.

In some instances, it may be determined at operation 225 that thepayment network operator does not manage the PAN or have access to thePAN. Accordingly, the payment network operator may map the PAC to theAcctID and subsequently send the AcctID corresponding to the PAC (andthus the AcctCode used in the present transaction) to the issuer who maythen map the AcctID to the PAC. The issuer may be informed of the AcctIDcorresponding to the AcctCode by the payment network operator when thepayment network operator generated the AcctID and assigned it to theAcctCode. The issuer may use the PAN in the further processing of thetransaction, including, for example, clearing, settlement, and otherpayment device (e.g., card) management functions.

FIG. 3 is an illustrative block diagram of a system 300 that may supportand facilitate aspects of the processes disclosed herein. In someregards, system 300 discloses a number of entities that may be involvedin processing a transaction that relies on a payment device having anaccount code thereon and/or in (not a PAN) and a user cardholder havingknowledge of a user code. In some aspects, system 300 may supportonline, ecommerce or card-not-present (CNP)transactions where thepayment device (e.g., card) is not physically present with the usercardholder at the merchant at the time the transaction is commenced.

Referring to FIG. 3, user cardholder 305 may be issued a payment device(e.g., a credit card, a personalized electronic wallet application forexecution by a mobile computing device, etc.) having an account code,AcctCode, printed on or encoded in or thereon. While the issuer issuesthe payment device with a corresponding PAN, the PAN is not distributedto or deployed with the payment device provided to user cardholder 305.In some aspects, user cardholder 305 may selectively and optionallyregister with payment network 370 in order to participate in amethodology disclosed herein including an issued payment device havingan AcctCode (not a PAN).

Additionally, user cardholder 305 may obtain a user code, UserCode, froman operator of payment network 370, where the payment network operatorgenerates and assigns the UserCode to user cardholder 305. Paymentnetwork 370 may receive requests for a UserCode via an account hashmanagement interface 335 that provides access to the payment network.Account hash manager 340 may determine and map the UserCode to itsassociated AcctCode.

Account hash manager 340 may also generate and assign an AcctID to theAcctCode and provide other hashing or mapping functions in some aspectsherein. For example, account hash manager 340 may operate to provide amapping of a PAC (e.g., AcctCode+UserCode) to an AcctID and, in aninstance payment network 370 will manage a PAN for the issuer, provide amapping of the PAC (e.g., AcctCode+UserCode) to the appropriatecorresponding PAN.

Regarding a CNP transaction for example, user cardholder 305 mayselectively and optionally pre-authorize one or more e-commercemerchants with payment network 370. This pre-authorization process mayinclude user cardholder 305 authorizing the payment network operator toprocess CNP transactions from specific, designated merchants in thefuture when payment network 370 receives requests to process CNPtransactions involving the designated merchants. In some aspects, usercardholder 305 may pre-authorize payment network 370 to provide thecardholder's UserCode associated with their AcctCode if payment network370 receives a request to process CNP transactions involving thedesignated pre-authorized merchant(s) and the user cardholder'sAcctCode.

To commence a CNP transaction, user cardholder 305 may submit theAcctCode (e.g., 12 numeric digits) printed on their credit card (ordisplayed in a chip card's display, presented in a user interface screenof an electronic wallet app, etc.) and issued by account issuer 360 to amerchant's online payment terminal 315. In this example, the merchant isone of the designated pre-authorized merchants for the user cardholder.In some embodiments, the AcctCode may be deployed via an electronicwallet application executing on an electronic device belonging to and inthe possession of the user cardholder. Payment terminal 315 may generatean authorization request and forward the authorization request topayment acquirer 320 that processes the transaction on behalf of themerchant involved in the transaction. Payment acquirer 320 may forwardthe authorization request including, at least, an identifier of themerchant and the AcctCode to payment network 370 via an acquirercommunication processor 325 that interfaces with and provides access topayment network 370.

Upon receiving the authorization request, payment network 370 maydetermine whether the authorization request involves an AcctCode (notPAN). This determination may be based, at least in part, on the value ofthe AcctCode received in the authorization request. Payment network 370may also determine whether the authorization request involves apre-authorized merchant regarding the cardholder 305, where thisdetermination may be based, at least in part, on the value of a merchantidentifier received in the authorization request. In the instance it isdetermined that the current transaction does involve an AcctCode and apre-authorized merchant regarding the cardholder 305, then paymentnetwork 370 may operate to associate the user cardholder's UserCode withthe AcctCode to effectuate the formation of the PAC (e.g.,AcctCode+UserCode). As noted above, the payment network operator may mapthe PAC to the corresponding AcctID and, in an instance payment network370 will manage a PAN for the issuer, the payment network operator mayprovide a mapping of the PAC to the appropriate corresponding PAN.

Payment network 370 may, via global authorization processing module 345,provide an authorization message including the determined AcctID (in theinstance issuer 360 manages the PAN) or the determined PAN (in theinstance payment network 370 manages the PAN for the issuer) to issuer360. The authorization request including the AcctID or the PAN may becommunicated to the issuer with the assistance of an issuercommunication processor 350 that interfaces with payment network 370 anda payment processor 355 that may be employed to process transactions foraccount issuer 360. Upon receipt of the authorization request includingthe AcctID, issuer 360 may determine the PAN associated therewith byreferencing its repository of PANs. Having determined the PAN orreceived in the authorization request, issuer 360 may proceed todetermine an authorization response in reply to the authorizationrequest. Global clearing processing module 345 may be used in clearingfunctions performed by payment network 370.

FIG. 4. is a flow diagram of a process 400 that illustrates the entitiesassociated with some operations therein, in accordance with someembodiments herein. FIG. 4 shows a number of operations associated withan account holder 405 (i.e., user cardholder), an acquirer 410, apayment network 415, and an issuer 420. The operation performed by eachof these entities will now be discussed in the context of a transactioninvolving a payment device issued with a AcctCode (not PAN), asdisclosed in detail herein. Account holder 405 presents the paymentdevice including the AcctCode to a merchant at a merchant's locationsuch as a POS terminal, at operation 425. At operation 430, the accountholder enters their UserCode associated with the AcctCode at themerchant location.

Acquirer 410 associates the AcctCode with the UserCode at operation 435to form or otherwise determine the PAC. The associating of the AcctCodewith the UserCode at operation 435 may include, but is not limited to,the acquirer concatenating the UserCode to the AcctCode.

Payment network 415 receives the PAC in the example of FIG. 4 forauthorizing the current transaction using the determined PAC atoperation 440. Based on the PAC, the payment network may retrieve orotherwise determine the corresponding AcctID at operation 445.Furthermore, payment network 415 may determine whether the issuermanages the PAN at operation 450. If the issuer manages the PAN, that isif the issuer alone stores and knows the PAN, then the AcctID is sent toissuer 420 where the issuer maps the PAN to the AcctID at operation 460.If the issuer does not manage the PAN but the payment network does(i.e., the issuer distributes the PAN to the payment network), then thepayment network maps the AcctID to the PAN at operation 455. Atoperation 465, the PAN is passed for authorization and settlement.

An authorization response is received by the acquirer at operation 470to complete the authorization of the transaction. When the settlement ofthe transaction concludes, the transaction is completed at operation475.

FIG. 5 is a block diagram overview of a system or apparatus 500according to some embodiments. System 500 may be, for example,associated with any of the devices described herein, including forexample a merchant system device; an acquirer device or server; anapplication or service server of a payment network operator supportingor providing, at least in part, UserCode assignments, a PAC-AcctIDmapping and/or an AcctID-PAN mapping; and an account issuer device orsystem. System 500 comprises a processor 505, such as one or morecommercially available Central Processing Units (CPUs) in the form ofone-chip microprocessors or a multi-core processor, coupled to acommunication device 515 configured to communicate via a communicationnetwork (not shown in FIG. 5) to another device or system. In theinstance system 500 comprises a server (e.g., supporting the functionsand services provided by a payment network operator), communicationdevice 515 may provide a means for system 500 to interface with a clientdevice (e.g., an acquirer system or device). System 500 may also includea local memory 510, such as RAM memory modules. The system furtherincludes an input device 520 (e.g., a touchscreen, mouse and/or keyboardto enter content) and an output device 525 (e.g., a touchscreen, acomputer monitor to display, a LCD display).

Processor 505 communicates with a storage device 530. Storage device 530may comprise any appropriate information storage device, includingcombinations of magnetic storage devices (e.g., a hard disk drive),optical storage devices, and/or semiconductor memory devices. In someembodiments, storage device may comprise a database system such as arelational database management system and an in-memory database.

Storage device 530 stores program code 535 that may provide computerexecutable instructions for a mapping engine 535 for processing paymenttransactions including, in some aspects the PAC-AcctID mapping and/orthe AcctID-PAN mapping aspects associated with receiving a PAC in anauthorization request for a particular transaction, in accordance withsome processes herein. Processor 505 may perform the instructions of theprogram code 535 to thereby operate in accordance with any of theembodiments described herein. Program code 535 may be stored in acompressed, uncompiled and/or encrypted format. Program code 535 mayfurthermore include other program elements, such as an operating system,a database management system, and/or device drivers used by theprocessor 505 to interface with, for example, peripheral devices.Storage device 530 may also include data 540 such as database records orlook-up tables. Data 540 may be used by system 500, in some aspects, inperforming the processes herein, including the PAC-AcctID mapping and/oran AcctID-PAN mapping.

All systems and processes discussed herein may be embodied in programcode stored on one or more non-transitory computer-readable media. Suchmedia may include, for example, a floppy disk, a CD-ROM, a DVD-ROM,magnetic tape, and solid state Random Access Memory (RAM) or Read OnlyMemory (ROM) storage units and other non-transitory media, where thetangible non-transitory media may back up a “cloud” storage facility.Moreover, in-memory technologies may be used such that databases, etc.may be completely operated in RAM memory at a processor. Embodiments aretherefore not limited to any specific combination of hardware andsoftware.

In some embodiments, a cardholder herein may only submit the AcctCode(e.g., 12 numeric digits) for online transactions. In some instances themerchant's e-commerce system may optionally store the user cardholder'sAcctCode for future transactions. The merchant's e-commerce system may,at the time of a transaction, prompt the cardholder for their UserCode.In this manner, a full accounting of the AcctCode and the UserCode isnot stored in a merchant's (or merchant acquirer's) repository.

In some embodiments, in the event a cardholder's payment device or assetincluding the AcctCode (e.g., credit card, key chain mini-card, etc) isstolen or lost, the cardholder may request a replacement payment device,as opposed to requiring the issuance of a new payment device. Herein,the cardholder need only change their user code (UserCode) rather thanrelying on a new card being issued with a new PAN and expiration date.This aspect of some embodiments herein may be beneficial in situationswhere, for example, a card may be pre-registered for monthly orannualized payments. It is also noted that the UserCode may electivelybe changed at any time, in real time, by the card holder in the eventthe cardholder knows or suspects their UserCode has been compromised(e.g., skimmed, etc.).

In some aspects herein, embodiments of a payment device may be embodiedin an application, “app”, program, a browser (or browser-enabledapplication, extension, or add-on), computer-readable instructions andthe like executing on a mobile device, and a device having a processorto execute an application or program instructions. In some aspects, suchdevices may be said to be encompassed by disclosures herein referring toa electronic device or “mobile device”, even where such an electronicdevice may not necessarily be easily transported (e.g., a desktop PC).In some aspects, the mobile device may be a device including telephonyfunctionality and implemented as any number of different hardware,software, and combination thereof configurations.

Embodiments have been described herein solely for the purpose ofillustration. Persons skilled in the art will recognize from thisdescription that embodiments are not limited to those described, but maybe practiced with modifications and alterations limited only by thespirit and scope of the appended claims.

What is claimed is:
 1. A computer-implemented method, the methodcomprising: receiving an authorization request associated with atransaction, the authorization request including an account code;receiving a user code to associate with the account code; associatingthe account code and the user code together to form a payment accountcode; determining an account identifier corresponding to the paymentaccount code; determining whether to map the payment account code to aprimary account number (PAN); mapping, in response to the determinationthat the payment account code is to be mapped to the PAN, the paymentaccount code to the PAN to ascertain a PAN corresponding to the paymentaccount code; and sending the authorization request to be authorized,the authorization request including the PAN.
 2. The method of claim 1,wherein the associating of the account code and the user code togetherto form the payment account code comprises concatenating the accountcode and the user code to each other.
 3. The method of claim 1, whereinthe associating of the account code and the user code together to formthe payment account code comprises replacing at least a portion of thereceived account code with the user code
 4. The method of claim 1,wherein the payment account code comprises a 16-digit numeric string. 5.The method of claim 1, wherein the user code is received as part of theauthorization request and is distinct from the account code.
 6. Themethod of claim 1, wherein the user code is received from a user.
 7. Themethod of claim 1, wherein the determining of whether to map the paymentaccount code to the PAN is based on, at least in part, whether a recordof the PAN is maintained by a third party.
 8. The method of claim 7, inan instance the PAN is maintained by a third party, further comprises:determining not to map the payment account code to the PAN; and sendingan authorization request including the account identifier to beauthorized, the PAN to be determined by the third party.
 9. The methodof claim 1, further comprising maintaining a record of a mapping betweenthe account identifier and the payment account code.
 10. An apparatuscomprising: a processor; and a memory device in communication with theprocessor and storing program instructions thereon, the processoroperative with the program instructions to: receive an authorizationrequest associated with a transaction, the authorization requestincluding an account code; receive a user code to associate with theaccount code; associate the account code and the user code together toform a payment account code; determine an account identifiercorresponding to the payment account code; determine whether to map thepayment account code to a primary account number (PAN); map, in responseto the determination that the payment account code is to be mapped tothe PAN, the payment account code to the PAN to ascertain a PANcorresponding to the payment account code; and send the authorizationrequest including the PAN to be authorized.
 11. The system of claim 10,wherein the associating of the account code and the user code togetherto form the payment account code comprises concatenating the accountcode and the user code to each other.
 12. The system of claim 10,wherein the associating of the account code and the user code togetherto form the payment account code comprises replacing at least a portionof the received account code with the user code
 13. The system of claim10, wherein the payment account code comprises a 16-digit numericstring.
 14. The system of claim 10, wherein the user code is received aspart of the authorization request and is distinct from the account code.15. The system of claim 10, wherein a record of the PAN is not stored bythe system.
 16. The system of claim 10, wherein the determining ofwhether to map the payment account code to the PAN is based on, at leastin part, whether a record of the PAN is maintained by a third party. 17.The system of claim 16, in an instance the PAN is maintained by a thirdparty, further comprises: determining not to map the payment accountcode to the PAN; and sending an authorization request including theaccount identifier to be authorized, the PAN to be determined by thethird party.
 18. The system of claim 10, further comprising maintaininga record of a mapping between the account identifier and the paymentaccount code.
 19. The system of claim 10, wherein the user code isreceived from a user.